we're adding a dependency on a component in gz-common here so just want to check if this can be backported to a release branch? @scpeters or @j-rivero

yeah, we usually avoid adding dependencies to stable releases

I see some examples of using OPTIONAL_COMPONENTS with find_package, and I also see that gz_find_package supports that argument, though I don't see it in use anywhere, but you should be able to change this instance to find_package if there are bugs in the gz_find_package implementation.

The main issue will be that you would have to wrap the #include <gz/common/Profiler.hh> statement in a separate header (such as ogre/src/GzCommonProfiler.hh and ogre2/src/GzCommonProfiler.hh) that also defines a no-op version of the GZ_PROFILE macro. It's possible but a bit of work

If we chose to release it anyway, we would need to update the build dependencies in each gz-rendering release repo:

• https://github.com/gazebo-release/gz-rendering10-release/blob/185d20639b62bbbfa2f7b626cbd7c02bf5a8bd53/ubuntu/debian/control#L5-L22

ok got it. If we want to backport this, we can try adding it as an optional component as suggested.

If we chose to release it anyway, we would need to update the build dependencies in each gz-rendering release repo:

If I understand correctly, we don't necessarily need to release it with the profiler dependency. Currently we're just adding remotery profiling points and we expect that users can only do profiling from source build by setting the ENABLE_PROFILER flag to true.

I believe by default, it's compile-time dependency (need header for define definition)

If I understand correctly, we don't necessarily need to release it with the profiler dependency. Currently we're just adding remotery profiling points and we expect that users can only do profiling from source build by setting the ENABLE_PROFILER flag to true.

I believe by default, it's compile-time dependency (need header for define definition)

ok, you're right. I think what I meant to say was that if we wanted to just add profiler as a required component that we would have to update the debian metadata in order for it to compile, but as you point out the profile points wouldn't be active; they would still need to build from source to use the profiling.

So yeah, I think OPTIONAL_COMPONENTS in backports is the way to go

Nice. Who should do backports? Bot or maintainers or I should prepare PRs to other branches?